正式的应用程序框架是否太多了?

发布于 2024-07-09 22:00:50 字数 896 浏览 10 评论 0原文

我们的商店为各种垂直行业设计和创建定制软件应用程序。 目前,我们的大部分开发都使用 Csla 框架的修改版本。

它是一个很棒的框架,支持多种与数据库通信的方式,直接、远程、WCF 等。 它提供了大量的功能,其中许多功能我们并不使用。 该框架的优点很多,其中最大的优点是 Rockford Lhotka 在新技术方面领先一步,这意味着我们不必进行研究。 该框架的缺点是,您受到创建者如何实现更改和技术以及您不使用的所有功能的支配。

随着 Linq-to-Sql 的出现,我们正在认真考虑进行切换,因为生成的很多内容都是纯粹的数据访问,但通过创建部分类,我们可以扩展数据访问并提供业务逻辑。 我们还可以创建一些正式的接口来处理业务逻辑。 可以使用/创建我们的规则管理器,等等。 简而言之,我们将开发自己的应用程序框架。

我注意到 Jeff Atwood 在 PDC 讨论 ASP.NET MVC 框架2008 年,他主要处理一个项目,而且看起来他正在使用部分类扩展 Linq-to-Sql。 这种架构似乎证明了这样一个事实:代码易于维护,可以快速添加新功能,可以快速修复错误,并且在大多数情况下都表现良好。

我只是好奇其他用户的想法是什么? 我是否疯狂地放弃我们的框架而选择我认为更容易使用且更可维护的东西?

Our shop designs and create custom software applications for a vareity of vertical industies. We currently use a modified version of the Csla framework for most of our development.

It's a great framework, supports a vareity of ways to communicate with a database, directly, remoting, WCF and so on. It offers a ton of features, many of which we do not use. The pros of the framework are numerous, the big one being the Rockford Lhotka is a step ahead when it comes to new technology, meaning we don't have to do the research. The cons of the framework are the fact that you are at the mercy of how the creator implements changes and technology and all the many features that you do not use.

With the advent of Linq-to-Sql we are seriously looking at making to switch, granted a lot of what is generated is purely data access, but by creating partial classes we could extend the data access and provide business logic. We could also create some formal interfaces for working with the business logic. Could use/create our rules manager, and so on. In a nutshell we would be growing our own application framework.

I noticed during Jeff Atwood's discussion the ASP.NET MVC framework at PDC 2008, he was primarily working with a single project, and it also looked like he was extending Linq-to-Sql with partial classes. This architecture seems to demonstrate the fact that the code is easily maintainable, new features are quickly added and bugs are quickly fixed, and that it performs well ... most of the time.

I'm just curious as to what other user's thoughts are? Am I crazy to abandon our framework for something that I perceive is easier to use and more maintainable?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

ι不睡觉的鱼゛ 2024-07-16 22:00:50

该框架的缺点是事实
你受到如何的摆布
创建者实施更改并
技术和所有众多功能
您不使用的。

使用 LINQ 似乎您也会遇到这些相同的缺点,因此在进行更改时请记住这一点。 无论如何,您应该在进行这样的飞跃之前进行完整的分析,也许可以通过移植一个较小的现有应用程序或其中一个应用程序的子集作为案例研究。

The cons of the framework are the fact
that you are at the mercy of how the
creator implements changes and
technology and all the many features
that you do not use.

It would seem that you will be exposed to these same cons with LINQ so keep that in mind when making a change. In any event you should do a complete analysis before making such a leap, perhaps by porting one of the smaller existing apps or a subset of one of the apps as a case study.

勿忘心安 2024-07-16 22:00:50

我读了 Rick Strahl 写的一篇不错的博客,名为 A Simple Business Object Wrapper for LINQ to SQL 这回答了我的一些问题。 他花了一些时间解释他对框架的观点。

I read a good blog by Rick Strahl called A Simple Business Object Wrapper for LINQ to SQL that answers some of my questions. He takes some time an explains his viewpoints on frameworks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文