不知道这个设计是一个好主意还是一个极其愚蠢的主意？
使用 C#、asp.net 3.5、SqlServer 2005，
尝试将一些控制反转和 3 层架构合并到我当前的任务中。
不知道这是一个好主意还是一个极其愚蠢的主意：
我创建了一个用户界面层、一个业务层和一个数据层。
UI 收集 4 个值，News 是业务层类的实例（称为 c），并使用 4 个值对其进行初始化。
然后，UI 调用业务层类的该实例的方法来保存数据。
业务层类方法创建一个tsql字符串，例如
String.Format(@”insert into table1(col1,'col2','col3',col4)values({0},{1},{2},{3} ); 选择@@identity”, c.one, c.date1, c.date2, c.four) ;
并将字符串传递给数据层中类的 int 方法。
数据层使用该字符串作为 ExecuteScalar 的 CommandText 并将 @@identity 返回给业务层。
我将使用同一概念的变体通过数据读取器检索数据。
数据量不会很大，并且这不会是一个大容量的应用程序。
我过去这样做的方法是将ui中收集的4个值传递给业务层到数据层设置sqlparms，将值传递给存储过程等，然后将它们传递回业务层， ETC。
Using C#, asp.net 3.5, SqlServer 2005,
Trying to incorporate some inversion of control together with 3-tier architecture into my current assignment.
Don’t know enough to know if this is a great idea or an incredibly dumb one:
I have created a User Interface Layer, a Business Layer, and a Data Layer.
The UI collects 4 values, News an instance of a Business Layer class (call it c) , initializing it with the 4 values.
The UI then calls a method of that instance of the Business Layer class to save the data.
The Business Layer class method creates a tsql string such as
String.Format (@”insert into table1 ( col1, ‘col2’, ‘col3’, col4) values ({0}, {1}, {2}, {3}); select @@identity”, c.one, c.date1, c.date2, c.four) ;
and passes the string to a int method of a class in the Data Layer.
the Data Layer uses the string as the CommandText of an ExecuteScalar and returns the @@identity to the Business Layer.
I would use a variation of the same concept to retrieve data through a datareader.
The amount of data is not going to be large and this isn't going to be a high volume application.
The way I have done this in the past was to pass the 4 values collected in the ui, through the Business Layer to the Data Layer set up sqlparms, pass the values to a stored procedure, etc, pass them back to the business layer, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
哦亲爱的！有太多的话要说，我什至不知道从哪里开始。
首先，当您左右新建类时，我真的不明白 IoC 适合哪里。
接下来，您将强制 BL 层构建 SQL 语句，但它不应该这样做。更糟糕的是，您基本上是通过连接字符串来获取 SQL 语句。这是一种非常非常可怕的做法（请参阅 SQL 注入）。
现在，我在你的 BL 中并没有真正看到任何“业务逻辑”。而且你正在搞乱原始的 ADO.NET，这在当今是一个巨大的禁忌（除非你正在优化性能）。查看 NHibernate 或 BL 工具包。
这是我的推荐。了解服务层的全部内容，并尝试充实系统中的“服务”。由于您现在实际上没有任何“业务逻辑”，因此我认为
IFooPersistenceService是唯一的服务。接下来，了解 MVP 和 MVC。这将帮助您更好地构建 UI。
最后，这是我对整体控制流程的看法。
用户以某种形式输入多个值，然后单击“保存”。您的
IView引发Saved事件，该事件由IPresenter处理。然后，它从IView的属性中获取这些值，创建一个业务对象（或就此而言的对象图）来保存这些值，调用IFooPersistenceService（使用Foo是对象的名称）将其保存到数据库。IFooPersistenceService调用您选择的任何 ORM，并将@@SCOPE_IDENTITY的值返回给IPresenter。一旦您开始拥有任何类型的逻辑，请在
IPresenter和IFooPersistenceService之间添加一个附加层来保存所述逻辑。另请参阅此（递归地）。
Oh dear! There's so much to say I don't even know where to start.
First off, I don't really see where does IoC fits here as you're
newing up classes left and right.Next, you're forcing your BL layer to construct an SQL statement, which it shouldn't do. What's even worse is that you're basically concatenating strings to get an SQL statement. This is a horrible, horrible practice (see SQL injection).
Now, I don't really see any "business logic" inside of your BL. And you're messing with raw ADO.NET, which is a huge no-no nowadays (except when you're optimizing performance). Check out NHibernate or BLToolkit.
Here's what I recommend. See what Service Layer is all about and try to flesh out "services" in your system. Since you don't really have any "business logic" for now, I see a
IFooPersistenceServicebeing the only service.Next, read about MVP and MVC. This will help you build your UI better.
And finally, here's how I see the overall flow of control.
User enters several values in some form and clicks "Save". Your
IViewraises aSavedevent, which is handled by theIPresenter. It then fetches these values from properties of theIView, creates a business object (or object graph for that matter) to hold these values, callsIFooPersistenceService(withFoobeing the name of an object) to save it to the DB.IFooPersistenceServiceinvokes whatever ORM you choose and hands back the value of@@SCOPE_IDENTITYto theIPresenter.As soon as you start having any kind of logic, add an additional layer between
IPresenterandIFooPersistenceServiceto hold the said logic.See this (recursively) as well.
不，我认为你的新方法比你以前的方法差很多。如果不小心的话，使用
String.Format会让您容易受到SQL注入攻击。如果您实际上没有在“业务逻辑”层中执行逻辑，我只需将其删除并让您的“数据层”调用存储过程。
No, I think your new way is a lot worse than your previous way. Using
String.Formatleaves you open to SQL injection attacks if you aren't careful.If you aren't really doing logic in your "Business Logic" layer, I would just remove it and have your "Data Layer" call the stored proc.
如果它对您（和您的团队）有意义并且按预期工作，那么无论它是什么，它都是一个很好的设计模式。
软件的主要技术要求是降低复杂性。如果你正在做的事情会降低你和你的团队头脑的复杂性，那就让范式见鬼去吧。
If it makes sense to you (and your team) and it works as intended, it's a fine design pattern, no matter what it is.
Software's Primary Technical Imperative is to reduce complexity. If you are doing something that reduces complexity in you and your team's mind, to hell with the paradigms.
我对 Web 应用程序中良好设计的看法是，业务层是您以面向对象的方式对应用程序进行建模并定义业务规则的地方。业务层是应用程序的核心。在典型的 Web 应用程序中，您很多时候只是通过业务层传递数据，但它仍然在数据和 ui 之间创建了良好的分离，无论如何，它是非常容易编写和维护的代码，因此如果出现这种情况，请不要太担心似乎是不必要的代码。
为了使您的业务层面向未来并且易于测试，它不应该了解它使用的任何外部服务，它应该只定义服务应交付给您的应用程序的内容的合同，因此您为您的服务创建接口（ IDataStorage、IMailService、ILogger...）。这还允许您轻松地交换服务实现，因为它们比您的核心业务模型更容易发生变化。
您可以将 DAL 视为一项服务，允许您从持久性存储中存储和检索数据，这可以是 xml 文件、Web 服务或更可能是数据库。通过这种方式，您的 DAL 是一种从持久存储中获取数据并将其转换为您的业务实体的服务。
当涉及到 UI 时，理想情况下，您应该以允许不同 UI（Webforms、mvc、silverlight）的方式创建业务层界面。如果您创建一个好的应用程序，它将存在很多年，并且 UI 可能会更改很多次，并且很多时候会创建多个 UI。您的业务层不应该关心您使用什么作为 UI 层，这样您就可以在各层之间实现良好的分离。
My take on a good design in a webapp, is that the Business Layer is where you Model your application in an object-oriented way and define your business rules. The business layer is the core of your application. In a typical web app you will many times just pass data through the business layer, but it still creates a good separation between data and ui and anyways it is code that is very easy to write and maintain so don't worry to much if this appears to be unnecessary code.
To make your Business layer future proof and easy to test it should not have any knowledge of any of the external services it uses, it should just define a contract of what the services should deliver to your app, therefore you create interfaces for your services(IDataStorage, IMailService, ILogger...). This also allows you to easily swap the service implementations as they are much more a subject of change than your core business model.
You can consider your DAL as just a service the allows you to store and retrieve your data from a persistant store, this can be an xml file, web service or more likely a database. In this way your DAL is a service that gets data from your persistant store and translates this into your business entities.
When it comes to UI you should ideally create your business layer interface in a way that would allow for different UIs (Webforms, mvc, silverlight). If you create a good application it will live for many years and the UI will likely change many times and many times several UIs will be created. Your business layer should not care what you use as an UI layer, in this way you get a good separation between your layers.